home *** CD-ROM | disk | FTP | other *** search
/ Atari Mega Archive 1 / Atari Mega Archive - Volume 1.iso / lists / gem / l_1199 / 1113 < prev    next >
Text File  |  1994-08-27  |  9KB  |  208 lines
  1. Subject: Digested
  2. Date: Fri, 29 Jul 1994 16:24:32 +1000
  3. From: Warwick Allison <warwick@cs.uq.oz.au>
  4. Precedence: bulk
  5.  
  6.  
  7. Chris Ridd:
  8. >Warwick writes:
  9. >>*.papyrus*.key.openFile: KEY = ^O
  10. >The type [KEY] would not be required if we could more completely specify the
  11. >attribute-pattern string. eg <application name>.<function>.<attribute>
  12. >papyrus.opendoc.key     "^O"
  13.  
  14. That's a better idea than mine.  Okay, some of the obvious ones are:
  15.  
  16. Name       Values
  17. ------     ------
  18. key        std keyname, or scancode, or blank for no binding
  19. text       String of ascii characters, delimited by end-of-line
  20. name       String of ascii characters, delimited by end-of-line
  21. num        Decimal number in ascii, 0xHexadecimal number
  22. geometry   [ Width "x" Height ] [ "+" Xoffset "+" Yoffset ] - all in decimal.
  23. file       Filename in ascii, extension gives clue to type.  (full path only?)
  24. font       <fontname>@<fontsize>
  25. color      Colour name or hex specification (other?)
  26. flag       yes/on/true/oui/ja/1, no/off/false/non/nein/0
  27.  
  28. [Reminder: we only have to specify them, not implement them]
  29.  
  30. >I'm uncertain about the idea of application-types... How many dtp
  31. >packages or word processors is a user likely to have?
  32.  
  33. You're probably right.  It slows down all the application-specific pattern
  34. matching too.
  35.  
  36. <application-name>.<attribute-name>.<attribute-type>
  37.  
  38. Only attribute-name can have internal "."'s.
  39.  
  40. myWord.helpDialog.confirm.key: Return   (attribute-name = helpDialog.confirm)
  41. myWord.quitDialog.confirm.key:
  42.  
  43.  
  44. Now, as soon as we vote on the key shortcuts, we can put it in this form
  45. and see what it looks like.  (With "atariworks.selectAll.key: Alt-#*") :)
  46.  
  47.  
  48. Kevin O'Donovan:
  49. >This is what I'm currently thinking:
  50. >Left button as in X
  51. >Right button over a text entry area does paste
  52. >Right button over a widget label does an activate. In this case whenever
  53. >the mouse moves over such an activate area it will change form to an icon
  54. >of a mouse with the right button highlighted (black as opposed to white)
  55.  
  56. I like it, but why can't you just use the left button on the label for
  57. the activation?
  58.  
  59. >Now there I agree, but I'm quite happy to let the individual user make his own
  60. >mind up. If your library enforces your likes/dislikes then its flawed.
  61.  
  62. Agreed.  Some people hate click-to-type, others hate point-to-type.  For
  63. single-tasking systems, the user rarely changes focus, so it is not really
  64. an issue.  But in multitasking systems, it is a BIG issue.  For example,
  65. I am cutting and pasting this digest back and forth from my mail reader.
  66. If I was running under GEM, I would like to not have to top that mail reader
  67. window in order to cut text from it (since it is not overlapping this
  68. window I am typing the digest into).  In setting these standards, we must
  69. keep in mind FUTURE user behaviour, as the applications that follow our
  70. standard will be 90% of FUTURE apps and 10% of past apps (upgraded and
  71. preconformant).
  72.  
  73. >>Dialogs in Windows (on/off)
  74. >I assume by this you mean wether the dialogs are modeless or not (since
  75. >you can't do modeless dialogs that aren't in windows without a lot of
  76. >hacking)? If that's the case then I don't think this is something you can
  77. >really switch on or off. Nor can I see any reason why a user would want it
  78. >off.
  79.  
  80. `modal dialogs in windows'.  The only reasons the user might not 
  81. want it is that form_do() dialogs are faster, since they can use
  82. save-unders for redraw, rather than redraw events.  This is expecially
  83. useful if they use your app with a program for which window redraws are
  84. expensive (eg.  some DTP programs).  It needs to be configurable so
  85. that users of faster machines get the benefits of
  86. modal-dialogs-in-windows.  
  87.  
  88. >> [list of other attributes]
  89. >Not convinced these need to be in the file, but I don't really care either way.
  90.  
  91. Remember:  these do NOT need to be in the file, they just need to be
  92. defined as possibilities, so as to have an agreed-upon-name (not an
  93. agreed-upon-value though).
  94.  
  95. Hollis said:
  96. > I don't quite think you understand how event_multi handles the mouse.  If
  97. > you move the mouse and you don't have a timer set, you will never get a
  98. > mouse movement message, as they are always being returned.
  99.  
  100. The correct way to track every mouse movement is to watch a 1x1 pixel
  101. rectangle.  This is documented in many places.  (example uses are drawing
  102. programs and real-time drags)
  103.  
  104.  
  105. Hollis:
  106. ]If the button is no longer pressed when you process the message, top the
  107. ]window.  This means that the button was tapped on the window with the intent
  108. ]to bring it to the front.
  109.  
  110. Anything like that depends on how fast your machine is.
  111.  
  112.  
  113. Timothy Miller:
  114. >I realise this could be used in support of the 
  115. >app-defs file, but I have other reasons I don't like it.
  116.  
  117. Don't hide them inside, speak out!  Perhaps we will see your point and
  118. abandon our folly; perhaps we will explain something you've missed that
  119. changes your mind.  
  120.  
  121. >Yeah, sure... and let's make the user spend 5 hours on install, 4 of 
  122. >which is for configuration, and the last hour is for copying from floppy 
  123. >all the code for all the features that the user turned off.
  124.  
  125. Um... they have DEFAULTS.  The user only needs to change them if they
  126. want to.  Is this your objection to app_defs.sys?
  127.  
  128.  
  129. >KISS:  Keep It Simple, Stupid.  
  130.  
  131. These standards almost all specify HOW to do something IF you implement it.
  132. You are still free to keep it simple, stupid, and anything else you like.
  133.  
  134. >I am one of many people who have complained about Atari Works wiping out 
  135. >their documents when their little finger slips and hits Ctrl and A at the 
  136. >same time.
  137.  
  138. Now, if only you could change the shortcut...
  139.  
  140. By using a fixed standard, you cannot please all of the people all of the
  141. time.  By using an flexible standard, you can please everyone except those
  142. who think that Their Way Is Best.
  143.  
  144. >Just because it doesn't happen to you, doesn't mean it doesn't happen to 
  145. >you.  If you don't have astygmatism, does that mean that no one else does?
  146.  
  147. I do, but I don't expect everyone to wear glasses, nor for everyone to
  148. not wear glasses.  And I don't expect people with myopia to wear glasses
  149. if they want to wear contact lenses.  Just give people a little choice,
  150. and they're easy to please.
  151.  
  152. Hollis:
  153. >I doubt anyone would want to publish my documentation, because no one
  154. >would really care.  No one would buy any more Atari books anyway.  
  155.  
  156. This really isn't the attitude required on a list that is supposed to be
  157. looking at the FUTURE state of Atari GEM applications.
  158.  
  159. Hollis:
  160. >I think someone should post some standard code (in C, C++, Pascal, and
  161. >GfA Basic) so we can all use his/her code in our programs for APP_DEFS.  
  162.  
  163. Did y'all catch my code for pattern-matching against a string with wildcards?
  164. That's my contribution.
  165.  
  166. Couldn't we just write it in C and bind it to other languages?  Maybe have
  167. to convert it to ASM (via compiler) for some (can BASICs load C object files?)
  168.  
  169. >APP_DEFS was only designed to handle the keyboard equivalents of
  170. >menubar actions, and some actions of the program.  It was NOT designed
  171. >to handle the GUI itself.  
  172.  
  173. `was'?  It hasn't BEEN designed yet.  If it only handles keyboard equivalents,
  174. we're back following the meandering path of ASSIGN.SYS, DESKTOP.INF, etc.
  175. Either a flexible defaults standard, or nothing (that's why it is called
  176. `APP_DEFS.SYS', not `KEY_DEFS.SYS').
  177.  
  178. >Say, the user wants those two on one program, and doesn't want both of those
  179. >or just one of those on another program.  To overcome this, he would have
  180. >to change the configuration each time he ran the program.
  181.  
  182. The app-defs formats proposed so far all allow per-application and
  183. global specification of configurations.  Keep up.
  184.  
  185. >I don't think you have ANY idea of what you're talking about.  I am in no
  186. >way "misusing" AES.
  187.  
  188. Repeatedly using 0-length timers is misusing the AES, as it turns the
  189. application into the center of the world with AES being used as a key-getter
  190. and mouse-getter, rather than the event driven model used by the AES,
  191. and ALL other windowing systems.
  192.  
  193. Hollis:
  194. >Kev:
  195. >> And I don't think you understood what he was proposing. He doesn't need to
  196. >> track the mouse, he just needs to get a message when it leaves his window.
  197. >> Sounds like a job for a r